A leader in strategy and tech innovation at Tower Insurance, Daniel Maconaghie is an expert at identifying and deploying technologies that deliver huge operational expense and efficiency wins. Daniel has led his team in re-imagining their approach to put digital first, and by doing so deepening their customer relationships and business efficacy.
Fun fact: Daniel is famous at Ushur for achieving one of the quickest Ushur use case deployments to date. His team identified a use case, built, and tested their Ushur in about 2 hours - a true testament to his ability to solve problems alongside his team automation gurus!
We are thrilled to have Daniel here to answer all your questions about identifying automation projects and delivery strategy!
How to participate in the AMA:
Ask your question in this thread any time from now until December 9.
Ensure you get updates on this topic by clicking the âWatchingâ button below.
On December 9, Daniel will begin answering all of your questions! Youâll receive an email update when he replies.
Tower Insurance is headquartered in Auckland, New Zealand and is a large property and casualty insurer operating in New Zealand and the Pacific Islands. Read more about the challenges theyâve solved using Ushur here.
Hey Daniel! One of the biggest challenges in automation deployment is the handling of legacy systems already in place. Have you ever had a situation with folks preferring to continue following the conventional methodologies as long as the outcome is good at the end of the day? If so how did you or would have handled it?
Glad to have you here Daniel, here is my questions
When it comes to trying innovative, quick-to-deploy solutions in your organization, what impact have you seen in the culture and mindset of your team so that they seek new solutions for day-to-day challenges?
From my perspective, Iâm talking to lots of prospects and customers and sometimes I feel the prospect is far from this mindset of âletâs try to do things differentlyâ or âitâs ok if it doesnât work as long as it is quick and requires the least amount of effortsâ or âletâs start small and grow rather than trying to boil the oceanâ.
Definitely the biggest challenge was ensuring that the guardrails we put in place were safe & secure without stifling the creativity and passion of the Citizen Developers by being too restrictive. It was something that evolved a lot over our early use-cases to where it is today and I believe the success weâve had with that was ensuring that any processes introduced would support and empower our culture, not strangle it.
Aside from working with right IT teams early on to ensure all the boxes were ticked from a platform perspective, we needed to have processes in place for each use-case that could potentially be deployed.
On the Technology side, from our experience, we knew early on what these processes would need to address and roughly how that would look. The important part though was taking the Citizen Developers on the journey with us.
Quite often as individuals we can take for granted the journey we go through to become proficient at something to the level of where it is âsecond natureâ. Being aware of this fact with respect to IT Best Practices was crucially important for ensuring that we were having meaningful conversations with the Citizen Devs. We didnât want to end up with âjust do x, y & zâ we wanted to start the problems that x, y & z were created to solve and then go on that journey and arrive at the same conclusions together. This also had the added bonus of building rapport amongst the team, which is an added win.
As we scaled up over time we then leveraged these initial Citizen Devs to train, guide and support the next wave of Citizen Devs. Since they had been on the journey themselves and understood the âwhyâ, they were empowered now to take others on that same journey of understanding.
Hi Cameron, I personally havenât seen that problem so maybe weâre just lucky, haha!
On a serious note, that kind of situation sounds like an engagement problem. What I would do in that situation would be first seek to understand from the person(s) who are continuing the âoldâ way, to really get a feel for the possible reasons;
Are they properly trained on the new method/system?
Do they understand the âwhyâ? (as mentioned in my other response to John)
Are they even aware of it all?
Did we miss overlook something in the old way than canât be done with the new way?
We canât have a flow diagram for every possible reason that could occur, but one of the strongest things we can do is leverage a peer network. If youâre running a Citizen Developer program, or any training program for that matter, you can quickly identify the individuals who are embracing it and are passionate about it. Enabling these individuals to share and work with others was the easiest way we found to raise engagement with any new platform/tool/process, it was also one of the best ways we would find potential issues.
I tend to describe this kind of engagement spread as âviralâ - even if you donât run any active change campaigns (you should), it will still spread (in a good way!)
I think the biggest shift that we had to go through culture wise, was re-defining what âsuccessâ was. In traditional software development you tend to build and ship, then perform multiple iterations/releases on top of that. The âsuccessâ factors here tend to stem from the shipping the product (e.g. the first release/feature), alongside measurements of quality/engagement.
We took a slightly different approach - more in line with the principles of Lean Delivery, with ideas stemming from Eric Riesâs book The Learn Startup. Our success wasnât defined by shipping a particular engagement to our Customers, or on how successful that engagement was.
It was more along the lines of âWe think xyz might work, lets test that ideaâ and much like the famous Edison quote we didnât consider failure if the idea didnât work. We instead put emphasis on how many or how often we could experiment with different ideas in a safe way with a small amount of customers. When we found something that would stick (e.g. high engagement) then we would shift effort into fleshing that out more. Itâs important to note that we had business SMEâs working extremely closely with us on any particular initiative. Of course, you have to have the right type of work environment and senior leadership buy-in to support a culture like that, and we did.
I think a tell tale sign that a team is working in this fashion is by listening to the day-to-day conversations. You hear less restrictive-based sentences starting like âThat will be too hardâ or âWe donât do it that wayâ to more exploratory based ones like âI wonder ifâ or âletâs try thisâ.
Hi Janeen, I should have read further down the list, I would have saved part of my answer to John for this question, haha.
It has to be the fact that since they are a part of what is âhappeningâ rather than having it âhappen toâ them, it makes it so easy to get further buy-in with the âviralâ type engagement that I mentioned before. Business users and experts are seeing what their colleagues are doing and are actively seeking us out with their own ideas.
Thank you Daniel. That was insightful because one of the challenges in putting together a program of technology adoption is where to start. Guardrails not only provide the safety and security but also provide a structure to encourage that adoption. That âwhere do I startâ. Great stuff!
HI Daniel. I was going to asking you a question about benefits measurement and management but reading your answers to other question Iâm glad to see your emphasis on taking lean, experimental approaches to solve problems and that senior leadership buy-in and support is vital for succeeding.
In our organisation Iâm happy to say that we have senior leadership buy-in and support and weâre working hard to evolve our culture into something more lean and agile but we can often fall back into traditional ways of working and reportingâ for example - business case development, declaring expected âbenefitsâ before we implement.
So, my question: Do you have any tips on how to sustain the buy-in from senior leadership? For example, how do you keep them involved? How do you communicate success and failure? How do you ensure that benefits are sustained? Thank you.
Thanks for the reply Daniel!
I like how you described enabling advocates to connect with others on the team as a âviral spreadâ. Positivity and good impressions are always contagious!
I think this is something that we could have a chat about sometime, Iâm very interested to hear your insights too as I think it can be a deep topic.
When it comes to communicating success or failures we usually just take a very straight-forward transparent approach, but as I mentioned before I think an important aspect of this is emphasizing the narrative of experimentation - this is well understood amongst our senior leadership as we liken it to feature development on a traditional website which they have had a lot of exposure to (e.g. they understand the concept of A/B tests).
Sustaining benefits is something that weâve been focusing on now as enough time has passed so that the âhypeâ phase is over and weâre really trying to push for increased growth in terms of micro-engagement executions. We are heavily leveraging the divisional leaders amongst the business to do this, it makes it a lot easier when they can see that their team members are empowered (via the no/low-code platform) to be an actual part of the delivery team. We push that narrative a lot - that we provide the platform and give them the agency to experiment as much as they want in the âsandboxâ (with help as needed of course). I think this naturally âbubbles upâ to the Senior Leadership of those divisions as not only a great engagement story, but also enabling them to get the current facts/state-of-play directly from someone in their division who is an actual part of the delivery team.
Again, would love to chat further with you on this!
Thank you all for participating in this Ask Me Anything - and an extra big thanks to this monthâs expert, Daniel! This thread will now be locked, but feel free to start a new topic in the discussion forums to continue the conversation.